I disagree about it. There's nothing wrong about this signature:

	/**
	 * @template T of BackedEnum
	 * @param class-string<T> $class
	 * @param value-of<T> $value
	 */

I feel like UnresolvableTypeHelper should skip LateResolvableTypes.

I think that'd just hide the error. Currently value-of with generics and backed enums seems to be broken. And looks like #4548 might fix it 👀

Edit: I copied the snippet you referenced and the fix from #4548 and looks like that fixes it without the need of skipping LateResolvableTypes in UnresolvableTypeHelper

I'm sorry about sleeping on this. There are now conflicts. Please fix rebase and fix them. At least meanwhile I merged #4548.

Amazing. Yeah, I was waiting for that PR to be merged first. Will do in the evening 👍🏽

@ondrejmirtes Rebased and refactored new usages to methods too.

There is one test failing locally. Here it doesn't report error anymore. @VincentLanglet maybe you have any insights?

There is one test failing locally. Here it doesn't report error anymore. @VincentLanglet maybe you have any insights?

No idea like this, the PR is (too) big.
You can start by rebase again since there is conflict, but maybe the right way would be to split the replacement of method into smaller commit in order to check when the CI start to fail ?

There is one test failing locally. Here it doesn't report error anymore. @VincentLanglet maybe you have any insights?

No idea like this, the PR is (too) big. You can start by rebase again since there is conflict, but maybe the right way would be to split the replacement of method into smaller commit in order to check when the CI start to fail ?

The issue is that, with this PR an error is not reported whereas the test expects an error. This one

Can we say the test is wrong now and remove the error from there?

Can we say the test is wrong now and remove the error from there?

No. I don't think the test is wrong.
unlike a BackedEnum, value-of<UnitEnum> is unresolvable.

78ca602 fixes it. And doesn't break anything else.

78ca602 fixes it. And doesn't break anything else.

Nice, I prefer to let ondrej decide if this is the right way.

(Maybe LateResolvable::isNever should return no (?))

When reading the PR, it's unclear to me why sometimes

$exprType instanceof NeverType

is changed to !$exprType->isNever()->no() and sometimes to $exprType->isNever()->yes()

Is maybe possible ?

• If not, could we have consistency ? (it seems simpler to use yes that !no().
• Also if not, I wonder if the method should return boolean... (Or we will end up with not-caught mutant from mutation testing)

And about this question ? How did you decide between. ->yes() and ! ->no() every time you replace an instanceof check ?

And about this question ? How did you decide between. ->yes() and ! ->no() every time you replace an instanceof check ?

Initially I replaced them with just normal yes and no. But some tests were failing so I changed the conditions to think about maybe too. So currently if you see !no instead of yes it means it was making a test fail before.